One way that computer networks manage their resources is by using Open Systems Interconnection ("OSI") standards. OSI management uses managed objects to represent resources. FIG. 1 illustrates a conventional system in a computer network operating in an OSI environment. This system 100 includes a "manager" 110 (an application acting in the manager role) and an "agent" 120 (an application acting in the agent role). The agent 120 contains one or more managed objects (130.sub.1 -130.sub.t) ("MO") made visible to the manager 110 via the Common Management Information Protocol ("CMIP"), a discrimination component 140, and Event Forwarding Discriminators (150.sub.1 -150.sub.p) ("EFD") managed by the discrimination component 140. An agent 120 may contain a proxy agent coordinator ("PAC") 160 which provides the appearance of agents, or "proxy agents" (170.sub.1 -170.sub.m) for one or more devices (180.sub.1 -180.sub.m represented by managed objects (190.sub.1 -190.sub.m) using other existing protocols, such as the Simple Network Management Protocol ("SNMP"). The MOs (190.sub.1 -190.sub.m) made visible by proxy agents (170.sub.1 -170.sub.m) are outwardly indistinguishable from MOs (130.sub.1 -130.sub.t) on a non-proxy agent 120. Rather than interacting directly with a device, MOs (190.sub.1 -190.sub.m) on a proxy agent (170.sub.1 -170.sub.m) interact with a device via the management protocol supported by that device. Typically a manager will work with more than one agent.
All MOs have unique identifiers called Distinguished Names ("DN"). The DN's are organized in a tree-like or hierarchical structure. Each child MO is identified within the scope of its containing parent MO by an attribute of that child MO. An attribute consists of an attribute type and an attribute value. Using a directory mechanism, a manager 110 can determine to which agent a message should be sent to interact with a particular MO.
There are two types of messages that are sent between a manager 110 and an agent 120. The manager 110 can send request messages to MOs (130.sub.1 -130.sub.t) at agent 120 and receive response messages. The manager 110 can also receive unsolicited messages from agent 120. A MO (for example 130.sub.1) can emit a notification to indicate that some event has occurred concerning the resource represented by the MO 130.sub.1. To receive this information, the manager 110 must create one or more EFDs (150.sub.1 -150.sub.p) on the agent 120 containing the MO 130.sub.1.
FIG. 2A illustrates the structure of a conventional notification. A notification contains two groups of information. The first group is the "header" 202 which contains information such as the DN of the MO that emitted the notification and the type of event being described in the notification. The second group 204 is the event information.
FIG. 2B illustrates the structure of a conventional EFD. An EFD is just another type of MO that can reside on an agent. The EFD also contains two groups of information. The first group 206 is the EFD Object Information which includes the DN of the EFD, destination information (a list of managers to which the notifications should be sent), and the state information of the EFD MO. The second group 208 is a filter that determines which notifications should be forwarded. When a notification is forwarded from an agent to a manager, it is sent in a message called an Event Report ("ER").
FIG. 3 is a flow chart illustrating a conventional method of processing a notification emitted by an MO. When a notification is generated, it is sent to the EFDs, via step 302. The discrimination component of the agent sends (or forwards) the notification through each EFD on that agent, via step 304. The values in the filter of the EFD are then compared with the notification event information, via step 306. If the notification passes the criteria specified by the EFD's filter, via step 308, then an ER is sent to each of the managers listed in the EFD's destination information, via step 310.
For example, assume a manager 110 would like to be informed when the status of a resource changes. FIG. 4 illustrates this example. The manager 110 would create an EFD 150.sub.1 on the agent 120 that contains the MO 130.sub.1 that represents that resource. This EFD's filter would specify that only status changes should be forwarded, and the destination would be the manager 110 itself. When a status change occurs on the resource, the MO 130.sub.1 that represents that resource emits a status change notification 410. This notification 410 is presented to each of the EFDs (150.sub.1 -150.sub.p) on the agent 120. Since this notification 410 meets the criteria in the filter of one EFD 150.sub.1 on this agent 120, an ER 420 is sent to the manager 110. The ER 420 contains the DN of the MO 130.sub.1 that emitted the notification 410, so that the manager 110 knows which resource had a status change. A manager 110 typically manages more than one agent, so it would create similar EFDs that differ only in the DNs on each of the agents that it manages.
Although the above conventional process is adequate for MOs that interact directly with their associated resources, problems exist when the notification is generated by a proxy MO that is interacting with its resource via some other management protocol. FIG. 4B illustrates this problem. The problem arises because the PAC 160 can support more than one proxy agent (430.sub.1 -430.sub.n). An agent 440 that has a PAC 160 contains sets of EFDs (450.sub.1 -450.sub.n) that would each normally be on different agents. But since a notification must be sent to all of the EFDs (450.sub.1 -450.sub.n) on an agent 120, and since all of the EFDs that are created by the manager 110 on proxy agents (430.sub.1 -430.sub.n) are nearly identical, a notification emitted by a proxy MO, such as 460, on a proxy agent 430.sub.1 will be processed and forwarded not only by the set of EFD 450.sub.1 on proxy agent 430.sub.1, but also by all other sets of EFDs (450.sub.2 -450.sub.n) on other proxy agents (430.sub.1 -430.sub.n). The result is redundant processing, since each EFD on the proxy agents (160-1 through 160-r) must perform the same evaluation on the notification and the results will be the same, causing extra network traffic. Thus many ERs will be sent rather than just one which could possibly cause confusion for the managers, especially if the notification indicates that a resource has been created.
The ISO-Internet Migration/Coexistence (IIMC) group has developed one approach to the above problem by requiring that EFDs on a proxy agent be contained under a special managed object on that proxy agent. The discrimination component is enhanced so that notifications emitted by an MO on a proxy agent are sent only to the EFDs contained under the special managed object. Although this avoids the problem above, it introduces a new problem. This approach requires that the managers create their EFD's under the correct special managed object, i.e., the managers must know ahead of time which devices are supported by proxy agents and which are supported by non-proxy agents and handle the creation of the EFDs accordingly. This defeats the purpose of the proxy which is to hide differences from managers. This approach requires the existing manager applications to be at least partially rewritten and complicates the development of new managers. Thus, this approach is inflexible and cumbersome in its implementation.
Therefore, there exists a need for an event notification method and system which has the ability to distinguish between sets of EFDs on different proxy agents while maintaining the ability to hide the difference between proxy agents and non-proxy agents from managers. This system should be easy to implement and should not require changes to the programming of existing managers nor require new managers to be sensitive to the differences between proxy agents and non-proxy agents. The present invention addresses such a need.